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Abstract 

Ad-hoc  wireless  communication  among  highly  dy¬ 
namic,  mobile  nodes  in  a  urban  network  is  a  criti¬ 
cal  capability  for  a  wide  range  of  important  applica¬ 
tions  including  automated  vehicles,  real-time  traffic 
monitoring,  and  battleground  communication.  When 
evaluating  application  performance  through  simula¬ 
tion,  a  realistic  mobility  model  for  vehicular  ad-hoc 
networks  (VANETs)  is  critical  for  accurate  results. 
This  technical  report  discusses  the  implementation 
of  STRAW,  a  new  mobility  model  for  VANETs  in 
which  nodes  move  according  to  a  realistic  vehicu¬ 
lar  traffic  model  on  roads  defined  by  real  street  map 
data.  The  challenge  is  to  create  a  traffic  model  that 
accounts  for  individual  vehicle  motion  without  in¬ 
curring  significant  overhead  relative  to  the  cost  of 
performing  the  wireless  network  simulation.  We 
identify  essential  and  optional  techniques  for  model¬ 
ing  vehicular  motion  that  can  be  integrated  into  any 
wireless  network  simulator.  We  then  detail  choices 
we  made  in  implementing  STRAW. 

1  Introduction 

Communication  in  mobile  ad-hoc  wireless  networks 
(MANETs)  is  the  focus  of  extensive  research  due  to 
its  ability  to  enable  distributed  applications  among 


mobile  nodes  in  infrastructureless  environments.  Ve¬ 
hicular  ad-hoc  networks  (VANETs)  are  a  particu¬ 
larly  challenging  class  of  MANETs  characterized  by 
nodes  with  relatively  high  mobility  (speeds  between 
0  and  20  m/s).  In  addition,  unlike  many  other  mo¬ 
bile  ad-hoc  environments  where  node  movement  oc¬ 
curs  in  an  open  field  (such  as  conference  rooms  and 
cafes),  vehicular  nodes  are  constrained  to  streets  of¬ 
ten  separated  by  buildings,  trees  or  other  obstruc¬ 
tions,  thereby  increasing  the  average  distance  be¬ 
tween  nodes  and,  in  most  cases,  reducing  the  over¬ 
all  signal  strength  received  at  each  node.  Connectiv¬ 
ity  in  this  environment  is  essential  for  a  wide  range 
of  important  applications  including  real-time  traffic 
monitoring,  battleground  communication  and  other 
vehicular  distributed  systems. 

We  argue  that  a  more  realistic  mobility  model  with 
the  appropriate  level  of  detail  [9]  for  VANETS  is  crit¬ 
ical  for  accurate  network  simulation  results.  With 
this  in  mind,  we  designed  a  new  mobility  model  for 
VANETs,  STRAW  (STreet  RAndom  Waypoint),  that 
constrains  node  movement  to  streets  defined  by  map 
data  for  real  US  cities  and  limits  their  mobility  ac¬ 
cording  to  vehicular  congestion  and  simplified  traffic 
control  mechanisms. 

In  a  previous  paper  [5],  we  evaluated  and  com¬ 
pared  ad-hoc  routing  performance  for  vehicular 
nodes  when  using  STRAW  mobility  in  diverse  ur¬ 
ban  environments  to  the  performance  when  nodes 
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move  in  an  open  field  using  the  classical  random 
waypoint  (RWP)  model.  We  have  shown  that  the  per¬ 
formance  of  wireless  network  protocols  in  urban  en¬ 
vironments  is  dramatically  different  than  that  in  an 
open-field/RWP  scenario  and,  further,  that  the  type 
of  urban  environment  can  have  a  significant  impact 
on  the  performance  of  a  protocol. 

In  this  paper,  we  discuss  STRAW’S  design  in 
detail,  describe  a  reference  implementation  for  the 
SWANS  [3]  network  simulator  and  detail  the  perfor¬ 
mance  of  SWANS  for  several  interesting  cases.  The 
following  section  motivates  the  need  for  urban  mo¬ 
bility  models  in  ad-hoc  networks.  In  Sections  3  and 
4,  we  describe  the  features  of  a  realistic  vehicular 
mobility  model.  Section  5  details  the  implementa¬ 
tion  of  STRAW.  In  Section  6  we  discuss  and  evalu¬ 
ate  STRAW’S  performance  and  we  conclude  in  Sec¬ 
tion  7. 

2  Background 

Routing  messages  in  MANETs  has  become  the  focus 
of  much  research.  Some  of  the  routing  protocols  that 
have  achieved  prominence  include  topology-based 
protocols  (e.g.,  DSDV  [19],  DSR  [10],  AODV  [18] 
and  MRP  [17])  that  rely  exclusively  upon  IP  ad¬ 
dresses  to  locate  nodes  and  location-based  protocols 
(e.g.,  DREAM  [4],  GPSR  [11]  and  GLS  [14]  [16]) 
that  use  geographical  position  for  this  task. 

Proposed  protocols  are  compared  against  com¬ 
peting  or  ideal  ones  in  terms  of  metrics  such  as 
packet  delivery  ratio,  throughput,  latency  and  over¬ 
head.  Due  to  the  prohibitive  cost  and  time  constraints 
of  evaluating  ad-hoc  network  protocols  in  real-world 
deployments,  most  studies  rely  on  simulators  for  ex¬ 
perimentation  (e.g.  [20,  27,  2]). 

When  analyzing  different  protocols,  researchers 
often  adopt  a  common  set  of  simulation  parameters, 
such  as: 


•  Nodes  transmit  signals  that  propagate  with¬ 
out  error  to  other  nodes  within  a  radius  of 
250m  [13]. 

•  Nodes  move  in  an  open  field  according  to  a  ran¬ 
dom  waypoint  model  [26]  or  the  Manhattan  mo¬ 
bility  model  [7]  with  arbitrary  pause  times  and 
often  with  arbitrary  speed  distributions  between 
0  and  20  m/s. 

•  The  number  of  nodes  is  small  (i.e.,  <  100). 

Such  parameter  settings  are  clearly  inadequate  for 
many  MANETs,  and  particularly  for  VANETs  for 
the  following  reasons: 

•  In  [13],  the  authors  have  shown  that  the  rela¬ 
tionship  between  distance  and  signal  reception 
between  two  nodes  is,  at  best,  weakly  correlated 
over  large  distances.  It  is  also  well  known  that 
radio  transmission  range  does  not  form  a  circle 
and,  for  commodity  hardware,  rarely  achieves  a 
250  m  range  in  common  environments. 

•  Besides  settings  such  as  conventions  in  large 
conference  halls,  it  is  difficult  to  imagine  many 
scenarios  in  which  nodes  move  in  a  open  field. 
It  is  also  rare  that  node  mobility  can  be  accu¬ 
rately  modeled  by  random  waypoints.  Specif¬ 
ically  in  VANETs,  nodes  must  be  constrained 
to  roads  and  adjust  their  velocities  according 
to  traffic  control  mechanisms,  speed  limits  and 
the  behavior  of  nearby  vehicles.  Further,  in 
VANETs,  most  vehicles  attempt  to  follow  paths 
that  minimize  trip  duration  between  origin  and 
destination. 

•  In  VANETs,  nodes  in  urban  environments  can 
easily  number  in  the  thousands  or  tens  of  thou¬ 
sands. 
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Recent  interest  in  VANETs  [23]  [8]  has  encour¬ 
aged  researchers  to  design  experiments  that  better 
model  real  vehicular  traffic  scenarios.  For  exam¬ 
ple,  [12]  studies  the  behavior  of  the  MAC  layer  in 
a  vehicular  environment  using  arbitrary  road  plans 
while  [25]  and  [24]  use  the  CORSIM  traffic  mi¬ 
crosimulator  to  provide  mobility  traces  for  the  simu¬ 
lation. 

A  small  number  of  researchers  have  accounted 
for  street-constrained  motion  using  real  road  plans 
in  their  VANET  simulations.  In  a  closely  related 
work,  Saha  and  Johnson  [22]  incorporate  real  map 
data  into  the  NS-2  network  simulator.  A  limitation  of 
their  work,  however,  is  that  cars  do  not  interact  with 
one  another  and  there  is  no  notion  of  traffic  control, 
so  each  car  consistently  moves  at  or  near  the  esti¬ 
mated  speed  limit.  Because  nodes  move  at  unrealis¬ 
tic  speeds,  the  interaction  time  between  nodes  in  the 
simulation  can  be  significantly  different  from  reality. 
As  a  result,  the  wireless  network  interactions  among 
the  vehicles  are  similarly  invalid. 

In  [24],  the  authors  use  CORSIM  to  provide  a 
highly  accurate  model  of  vehicular  movement.  How¬ 
ever,  in  this  case,  the  vehicular  network  simulator  is 
detached  from  the  wireless  network  simulator,  mak¬ 
ing  it  difficult  to  close  the  feedback  loop  in  applica¬ 
tions  such  as  “traffic  advisory,”  where  participating 
nodes  may  alter  their  routes  based  on  real-time  ob¬ 
served  traffic  conditions.  For  example,  in  such  an  en¬ 
vironment,  the  participating  nodes  are  likely  to  alter 
their  route  to  reduce  travel  time  if  there  is  congestion 
along  their  current  routes.  In  this  case,  it  is  likely  that 
the  density  of  participating  nodes  along  such  “faster 
routes”  will  be  higher  than  on  slower  routes,  further 
altering  network  connectivity  by  increasing  interfer¬ 
ence. 

Many  accurate  models  for  simulating  vehicular 
traffic  exist,  so  why  build  a  new  model?  In  wire¬ 
less  network  simulators,  each  node  is  treated  individ¬ 
ually  for  purposes  of  sending  and  receiving  messages 


and  repositioning  the  node  on  a  field  according  to  its 
mobility  model.  Because  wireless  network  perfor¬ 
mance  and  location  are  tightly  coupled,  one  cannot 
attain  accurate  wireless  network  simulation  results 
unless  the  underlying  mobility  model  is  sufficiently 
accurate.  Unfortunately,  all  known  vehicular  traffic 
simulators  model  vehicular  traffic  according  to  traf¬ 
fic  flows  measured  in  number  of  vehicles  per  unit 
time.  In  these  models,  vehicles  are  treated  individ¬ 
ually  only  when  they  enter  or  leave  a  segment;  when 
inside  a  segment,  all  vehicles  are  indistinguishable 
from  each  other.  This  critical  design  choice  neces¬ 
sitates  an  alternate  traffic  model  to  ensure  accurate 
wireless  network  simulation  results. 

3  Fundamental  Abstractions 

In  this  section,  we  describe  the  essential  abstractions 
for  enabling  street-constrained  mobility  in  a  wireless 
network  simulator.  These  abstractions  represent  el¬ 
ements  that  should  be  implemented  in  all  simulators 
attempting  to  include  vehicular  traffic  mobility,  inde¬ 
pendent  of  the  traffic  model. 

At  the  most  basic  level,  the  simulation  must  ac¬ 
count  for  vehicles  that  are  directly  tied  to  the  posi¬ 
tion  of  radios  on  the  simulation  field.  Unlike  radios 
in  most  network  simulators,  where  the  size  of  the  ra¬ 
dios  is  considered  negligible,  the  radios  in  a  vehic¬ 
ular  network  must  be  assigned  to  an  object  of  some 
length.  Vehicular  size  can  be  uniform,  as  in  the  case 
of  using  an  average  vehicle  length,  or  vehicle  sizes 
can  vary  according  to  an  empirically-derived  distri¬ 
bution.  Further,  these  vehicles  cannot  be  allowed  to 
collide  with  one  another,  unless  the  resulting  colli¬ 
sion  is  modeled  appropriately. 

We  consider  two  approaches  to  modeling  a  sys¬ 
tem  in  which  collisions  can  occur.  In  the  particle- 
system  approach,  designers  model  a  system  that  al¬ 
lows  nodes  to  move  freely  and  use  collision  detection 
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to  react  to  collision  events.  This  reactive  approach  is 
appropriate  for  systems  in  which  nodes  are  “dumb” 
in  the  sense  that  they  do  not  attempt  to  alter  their  tra¬ 
jectories  according  to  environmental  conditions.  In 
our  vehicular  approach,  we  model  a  system  of  colli¬ 
sion  avoidance.  We  assume  that  vehicles  avoid  col¬ 
lisions  if  possible.  Further,  we  include  traffic  control 
mechanisms  that  force  drivers  to  follow  a  determinis¬ 
tic  admission  control  protocol  when  encountering  an 
intersection.  This  model  does  not  preclude  the  oc¬ 
currence  of  a  collision  event.  A  collision  event  can 
occur  if  one  or  more  vehicles  create  a  situation  in 
which  another  vehicle  cannot  avoid  collision  given 
its  mobility  constraints.  Such  a  collision  can  be  made 
to  impact  the  traffic  flow  in  the  vehicular  network. 

Another  essential  element  for  modeling  vehicu¬ 
lar  traffic  is  the  notion  of  a  road  segment ,  or  link. 
Formally,  a  road  segment  is  any  portion  of  a  road 
between  two  intersections.  Road  segments  can  be 
described  by  the  following  vehicle-independent  at¬ 
tributes: 

•  Shape- The  road  segment,  if  not  a  straight  line, 
can  be  represented  by  two  more  more  line  seg¬ 
ments  described  by  three  or  more  endpoints.  Of 
these  endpoints,  exactly  two  unique  points  must 
be  indicated  as  endpoints  for  the  entire  road  seg¬ 
ment. 

•  Length- The  length  of  the  road  segment  is  de¬ 
fined  by  the  sum  of  the  lengths  of  its  line  seg¬ 
ments. 

•  Width- The  number  of  lanes  in  which  vehicles 
can  move.  The  number  of  lanes  for  each  direc¬ 
tion  of  traffic  may  be  different. 

•  Afame-Each  road  segment  should  be  assigned  to 
a  street  name. 

•  Average  maximum  speed- This  is  often  repre¬ 


sented  by  the  posted  speed  limit  for  the  seg¬ 
ment. 

•  Class- The  type  of  road  (e.g.,  divided  highway, 
local  street,  etc.). 

•  Address- Each  road  segment  should  be  assigned 
start  and  end  addresses  for  both  sides  of  both 
segment  endpoints. 

A  related  element  is  the  intersection  abstraction. 
An  intersection  can  be  described  by  the  location  of 
the  center  of  the  intersection,  the  list  of  road  seg¬ 
ments  that  form  the  intersection  and  the  traffic  con¬ 
trol,  if  any,  employed  at  that  intersection.  It  may  also 
be  useful  to  include  information  such  as  the  dimen¬ 
sions  of  the  intersection,  the  number  of  streets  at  the 
intersection  and  the  types  of  streets  incident  on  the 
intersection. 

4  Vehicular  Mobility  Models 

We  now  present  vehicular  mobility  models  that  can 
be  included  in  a  network  simulator.  Each  model  sup¬ 
ports  variable  levels  of  detail  according  to  the  num¬ 
ber  of  parameters  that  are  defined  for  the  simulation. 
If  tuned  to  empirical  data,  the  parameters  can  im¬ 
prove  simulation  accuracy,  often  at  the  cost  of  in¬ 
creased  simulation  complexity  and  runtime. 

For  the  purposes  of  this  discussion,  we  divide  mo¬ 
bility  models  in  our  simulator  into  an  intra- segment 
component,  an  inter- segment  component  and  a  route 
management  and  execution  component  (Fig.  1).  We 
discuss  these  components  in  order. 

4.1  Intra-segment  Mobility 

The  intra-segment  mobility  model  controls  vehicu¬ 
lar  motion  from  the  point  at  which  a  vehicle  enters  a 
road  segment  to  the  point  at  which  it  exits  the  seg¬ 
ment.  For  this  component,  we  consider  only  the 
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Figure  1:  Illustration  of  vehicular  mobility  compo¬ 
nents  and  their  interactions  in  STRAW. 

well-known  car-following  model  of  vehicular  mo¬ 
tion.  At  the  simplest  level,  this  model  states  that  a 
vehicle  moves  at  or  near  the  same  speed  as  the  ve¬ 
hicle  in  front  of  it,  if  there  is  such  a  vehicle  within 
sufficient  range  of  the  current  vehicle.  Two  impor¬ 
tant  parameters  for  this  model  are  the  speed  of  the 
vehicle  being  followed  and  the  space  between  the 
followed  and  the  the  following  vehicle.  There  are 
many  ways  to  determine  this  intervehicle  distance, 
though  it  is  often  modeled  as  a  polynomial  function 
of  velocity  [21]. 

The  car-following  model  does  not  specify  a  vehi¬ 
cle’s  behavior  when  there  is  no  other  (nearby)  ve¬ 
hicle  to  follow.  We  assume  that  if  a  vehicle  is  not 
within  a  window  of  inter- vehicle  spacing  defined  by 


the  car-following  model,  it  accelerates  at  its  speci¬ 
fied  rate  until  reaching  the  vehicle’s  maximum  speed 
for  the  current  segment.  The  acceleration  rate  can 
be  constant,  dependent  on  the  current  speed  or  de¬ 
pendent  on  the  “type”  of  driver  (e.g.,  aggressive  or 
defensive  driver,  hurried  or  “Sunday”  driver).  Simi¬ 
larly,  a  vehicle’s  maximum  speed  can  be  set  to  the  the 
speed  limit  of  the  segment  being  traversed,  a  value 
assigned  according  to  some  distribution  around  that 
speed  limit  or  a  value  that  is  dependent  on  the  afore¬ 
mentioned  “type”  of  driver. 

The  intra-segment  model  must  also  specify  how 
non-following  vehicles  behave  when  encountering 
traffic  control.  We  consider  two  primary  forms  of 
traffic  control:  stop  signs  and  stoplights.  Some  forms 
of  traffic  control,  such  as  railroad  crossing  gates,  can 
be  generalized  to  one  of  these  types  of  traffic  control; 
others,  such  as  yield  signs  and  speed-limit  changes 
must  be  modeled  differently.  In  the  case  of  stop  signs 
or  red  stoplights,  an  approaching  vehicle  must  come 
to  a  stop.  A  yellow  stoplight  will  cause  a  vehicle  to 
come  to  a  stop  only  if  it  cannot  cross  the  intersec¬ 
tion  before  the  light  turns  red.  For  all  cases  in  which 
a  vehicle  must  come  to  a  stop,  the  vehicle  must  de¬ 
celerate  to  zero  velocity  before  encountering  the  in¬ 
tersection.  This  can  be  accomplished  with  a  single, 
global  deceleration  rate,  a  speed-dependent  rate  or  a 
rate  that  varies  between  vehicles  according  to  some 
distribution. 

Another  important  component  of  intra- segment 
mobility  is  the  notion  of  lane  changes.  A  vehicle  can 
change  lanes  only  if  there  is  space  available  in  an 
immediately  adjacent  lane.  We  consider  two  reasons 
for  lane  changing:  increasing  speed  and  preparation 
for  turning.1  In  the  former  case,  if  the  average  speed 
in  an  adjacent  lane  is  higher  than  the  current  lane,  it 


Arguably,  a  third  reason  for  changing  lanes  could  be  de¬ 
scribed  simply  as  “personal  preference,”  but  we  choose  not  to 
discuss  this  model  as  it  is  difficult  to  implement  accurately. 


5 


is  likely  that  the  lane  change  can  occur.  We  contend 
this  is  true  because  a  higher  average  speed  indicates 
not  only  that  the  lane  has  less  congestion,  but  that  the 
inter- vehicle  spacing  is  greater. 

For  the  purposes  of  changing  lanes  to  execute  a 
turn,  it  is  quite  likely  that  the  turning  vehicle  will 
cause  the  average  speed  of  the  current  lane  to  de¬ 
crease.  In  fact,  in  a  highly  congested  network,  there 
may  never  be  enough  space  to  change  lanes.  To  avoid 
indefinite  postponement,  it  is  common  for  a  driver 
in  one  lane  to  allow  space  for  a  driver  attempting 
to  change  to  the  current  lane.  One  can  model  this 
scenario  by  implementing  a  “signaling”  method  that 
causes  a  vehicle  in  the  adjacent  lane  to  make  room 
for  the  incoming  vehicle  with  some  probability. 

4.2  Inter-segment  Mobility 

The  inter- segment  mobility  model  determines  the  be¬ 
havior  of  vehicles  between  road  segments;  i.e.,  at  in¬ 
tersections.  The  inter- segment  mobility  model  can 
classify  intersections  according  to  the  number  of  in¬ 
tersecting  road  segments,  the  types  of  road  segments, 
and  the  type  of  traffic  control,  if  any,  at  the  intersec¬ 
tion.  In  essence,  the  inter-segment  mobility  model 
must  perform  admission  control  at  each  intersection. 
The  traffic-control  rules  vary  according  to  the  inter¬ 
section  type.  For  the  purposes  of  this  discussion, 
we  assume  that  the  Route  Management  and  Exe¬ 
cution  component  discussed  in  Section  4.3  has  al¬ 
ready  selected  the  next  road  segment  before  the  ve¬ 
hicle  encounters  the  intersection  and  that  the  vehicle 
discussed  is  not  currently  following  another  vehicle 
when  it  determines  the  action  to  take  at  the  intersec¬ 
tion. 

If  there  is  no  traffic  control  at  an  intersection, 
we  assume  that  there  is  a  merging  scenario  (e.g., 
from  an  access  ramp  onto  a  highway).  In  this  case, 
the  admission-control  mechanism  must  determine  if 
there  is  enough  space  for  the  incoming  vehicle  to 


enter  the  adjacent  lane  of  the  new  road  segment. 
If  so,  the  vehicle  may  enter;  otherwise,  the  vehi¬ 
cle  must  slow  down  until  space  becomes  available. 
Similar  to  the  lane-changing  component,  this  com¬ 
ponent  should  include  a  mechanism  to  prevent  in¬ 
definite  postponement. 

If  stop  signs  are  present,  the  admission  control 
mechanism  must  consider  the  number  of  intersec¬ 
tions  containing  the  signs.  For  instance,  if  the  in¬ 
tersection  is  an  “all-way”  stop,  a  vehicle  is  admitted 
into  the  next  road  segment  only  if  there  is  room  in 
the  next  stop,  and  only  after  coming  to  a  complete 
stop  and  waiting  until  its  turn  to  advance.  To  pre¬ 
vent  indefinite  postponement,  one  may  assign  a  total 
linear  ordering  to  streets  in  the  intersection  that  de¬ 
termine  the  order  of  release  from  the  stopped  posi¬ 
tion.  If  there  is  one  or  more  road  segments  without 
a  stop  sign,  vehicles  at  stop  signs  at  that  intersection 
must  yield  to  vehicles  without  a  stop  sign;  they  can 
cross  the  intersection  only  if  moving  to  the  next  road 
segment  would  not  cause  a  collision  with  another  ve¬ 
hicle  (e.g.,  cross  traffic).  Note  that  this  condition  ac¬ 
counts  for  the  case  where  a  vehicle  cannot  enter  an 
intersection  because  the  next  road  segment  is  already 
full. 

If  the  intersection  uses  stoplights  for  traffic  con¬ 
trol,  the  inter-segment  mobility  component  must 
consider  three  cases:  green,  yellow  and  red  lights.  Of 
these  colors,  there  can  be  more  than  one  type  (e.g., 
a  guarded  turn  signal).  When  a  vehicle  approaches 
an  intersection  containing  a  red  light,  it  should  be¬ 
gin  to  slow  down  at  the  location  where  the  vehicle’s 
deceleration  rate  curve  would  cause  the  vehicle  to 
stop  just  before  the  intersection.  Upon  encountering 
a  yellow  light,  the  vehicle  can  cross  the  intersection 
only  if  there  is  room  on  the  next  segment  and  if  the 
vehicle  cannot  safely  come  to  a  stop  before  the  in¬ 
tersection.  Finally,  upon  encountering  a  green  light, 
the  vehicle  may  cross  the  intersection  without  slow¬ 
ing  down,  provided  that  the  next  road  segment  is  not 
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full.  If  the  light  is  green  and  the  vehicle  executes  a 
turn,  the  vehicle  may  proceed  only  if  the  next  road 
segment  is  not  full  and,  in  the  case  of  a  left  turn, 
there  is  no  oncoming  traffic;  otherwise,  the  vehicle 
must  come  to  a  stop  at  the  intersection.  Assuming 
that  the  vehicle  can  make  make  the  turn,  it  must  slow 
down  to  the  maximum  turning  speed  for  that  vehicle 
before  executing  the  turn. 

4.3  Route  Management  and  Execution 

The  Route  Management  and  Execution  (RME)  com¬ 
ponent  determines  the  ordered  set  of  road  segments 
that  a  vehicle  will  traverse  during  a  simulation  run. 
It  must  ensure  that  the  sequence  of  road  segments 
along  a  vehicles  path  are  continuous.  The  segments 
along  a  path  can  be  chosen  deterministically,  sto¬ 
chastically  or  a  combination  of  both. 

In  this  paper,  we  discuss  two  RME  implementa¬ 
tions  for  STRAW  (STreet  RAndom  Waypoint).  The 
first  is  a  simple,  modified  random  waypoint  model 
that  requires  no  origin-destination  (OD)  informa¬ 
tion.  Unlike  traditional  random  waypoint  models, 
this  model  determines  a  vehicle’s  trajectory  at  each 
intersection;  namely,  a  vehicle  will  make  a  turn  at  an 
intersection  with  a  specified  probability  that  can  be 
independently  assigned  to  each  vehicle. 

The  second  model  uses  OD  pairs  and  interarrival 
times  to  drive  the  mobility  in  the  network.  In  this 
model,  an  OD  pair  is  chosen  for  each  each  vehicle 
and  routes  are  initially  calculated  according  to  a  min¬ 
imum  cost  (e.g.,  fastest  time,  shortest  distance).  This 
model  can  be  configured  to  recalculate  a  vehicle’s 
route  if  the  cost  of  a  path  along  or  near  its  precalcu¬ 
lated  route  significantly  changes,  thus  enabling  each 
vehicle  to  react  to  traffic  information. 

Note  that  both  models  are  independent  of  the  un¬ 
derlying  vehicular  mobility  model.  We  detail  the  im¬ 
plementation  of  these  mobility  models  in  the  next 
section. 


5  Vehicular  Traffic  Simulation  Im¬ 
plementation 

In  this  section,  we  describe  the  implementation- 
specific  elements  to  enable  efficient  interaction  be¬ 
tween  the  fundamental  vehicular  network  constructs 
discussed  in  Section  3  and  the  mobility  model  dis¬ 
cussed  in  Section  4.  Although  our  implementation 
is  written  in  Java,  it  can  easily  be  ported  to  any  lan¬ 
guage  supporting  user-defined  types.2  Our  vehicular 
mobility  model  extends  interfaces  provided  by  the 
SWANS  [3]  simulator  in  the  j ist . swans .field 
package,  including  the  Field  interface,  which  en¬ 
capsulates  functionality  for  mapping  radios  to  loca¬ 
tions,  the  Mobility  interface,  which  provides  in¬ 
terfaces  for  implementing  the  mobility  model  and  the 
Spatial  interface,  which  provides  interfaces  for 
locating  nodes  in  the  Field.  The  classes  that  im¬ 
plement  our  vehicular  mobility  model  are  contained 
in  the  jist .  swans  .  field,  streets  package. 

Before  discussing  components  particular  to  vehic¬ 
ular  mobility,  we  present  some  basic  concepts  par¬ 
ticular  to  our  simulation  environment.  In  all  of  our 
simulations,  individual  vehicles  are  identified  by  a 
unique  integer  value  that  maps  directly  to  the  node 
id  assigned  to  the  vehicle’s  radio.  We  have  also  ex¬ 
tended  SWANS  to  incorporate  a  notion  of  a  penetra¬ 
tion  ratio;  i.e.,  a  percentage  of  vehicles  in  the  net¬ 
work  that  are  equipped  with  radios.  To  enable  inte¬ 
gration  with  our  network  simulator,  we  represent  ve¬ 
hicles  without  radios  simply  as  vehicles  with  radios 
that  cannot  send  or  receive.  This  enables  us  to  map 
node  IDs  directly  to  vehicle  IDs  consistently,  and  al¬ 
lows  vehicles  that  are  not  participating  in  network 
communication  to  interact  with  participating  vehi¬ 
cles. 


2Note  that  the  porting  of  our  implementation  is  best  accom¬ 
plished  in  an  object-oriented  language  due  to  our  reliance  on 
interfaces  and  hierarchies. 
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5.1  Model-independent  implementation 

This  section  details  the  implementation  of  model- 
independent  components  of  our  vehicular  mobil¬ 
ity  implementation.  These  components  are  en¬ 
capsulated  in  the  RoadSegment,  StreetName, 
Shape,  Intersection  and  SpatialSt reet s 
classes. 

Before  discussing  the  detailed  implementation  of 
these  classes,  it  is  important  to  describe  how  map 
data  is  loaded  into  the  simulator.  This  is  performed 
by  the  StreetMobility  abstract  class,  which  im¬ 
plements  the  Mobility  interface  and  is  extended 
by  the  RME  models  to  determine  the  next  road. 

Upon  initialization,  the  StreetMobility  class 
loads  street  information  from  files  containing  the 
road  segment  information,  road  segment  shape  and 
street  name.  Note  that  the  following  relationships 
hold:  each  road  segment  has  exactly  one  street  name 
and  zero  or  one  shape.  Further,  street  names  may  be 
assigned  to  one  or  more  road  segments,  while  shapes 
are  assigned  to  exactly  one  road  segment.  If  the  road 
segment  has  no  entry  in  the  shape  file,  the  segment 
forms  a  straight  line;  else  the  points  along  the  road 
are  described  by  information  in  the  shape  file.  The 
road  segment,  street  name  and  shape  data  are  stored 
in  flat  files  containing  fixed-length  records.  Thus, 
each  road  segment  entry  contains  a  pointer  to  its  cor¬ 
responding  shape  record  (if  any)  in  the  shape  file  and 
each  road  segment  contains  a  pointer  to  its  corre¬ 
sponding  street  name  record. 

When  the  StreetMobility  constructor  is 
called,  the  user  can  specify,  among  other  parame¬ 
ters,  the  latitude-longitude  position  of  the  bottom- 
left  (Southwest)  and  top-right  (Northeast)  corners 
of  the  region  to  which  vehicle  mobility  should  be 
limited.  Although  the  implementation  could  sim¬ 
ply  load  all  data  in  the  files,  for  some  municipali¬ 
ties,  the  memory  consumption  due  to  unused  map 
data  can  become  significant  when  the  target  region 


is  small.  To  reduce  memory  consumption,  only  road 
segments  that  contain  one  endpoint  in  the  specified 
region  are  loaded  into  the  simulator.  Similarly,  only 
street  names  and  shapes  associated  with  these  road 
segments  are  loaded. 

After  each  RoadSegment  is  loaded  into  the  sim¬ 
ulator,  a  reference  to  that  object  is  placed  in  a  Vec¬ 
tor.  The  RoadSegment  Vector  allows  fast  ac¬ 
cess  to  RoadSegments  identified  by  its  index  (an 
int).  This  is  particularly  useful,  for  example,  when 
determining  initial  vehicle  placement  using  random 
road  segments  and  when  determining  random  OD 
pairs.  A  reference  to  each  RoadSegment  is  also 
loaded  into  a  quad  tree,  or  hierarchical  grid,  con¬ 
taining  a  LinkedLists  of  Intersection  ob¬ 
jects  as  leaves.  An  Intersection  object  con¬ 
tains  a  LinkedList  of  RoadSegments,  a  lo¬ 
cation  representing  its  center  (in  latitude/longitude) 
and  a  count  of  the  number  of  streets.  Because  map 
data  is  often  imperfect,  a  RoadSegment  is  added 
to  an  Intersection  if  one  of  its  endpoints  is 
within  a  user-defined  distance  (5  m  is  usually  suffi¬ 
cient)  from  an  existing  Intersection.  The  In¬ 
tersection  class  also  provides  fields  and  meth¬ 
ods  to  facilitate  the  implementation  of  traffic  control. 
Because  Java  1.4.x  does  not  include  a  quad  tree  im¬ 
plementation,  we  use  the  SpatialStreet s  class 
(an  extension  of  the  Spatial  class  provided  by 
SWANS)  to  maintain  the  quad  tree.  The  degree  of 
the  quad  tree  can  be  specified  by  the  user  at  runtime. 

After  loading  RoadSegments  and  completing 
the  construction  of  the  quad  tree  of  Intersec¬ 
tions,  the  StreetMobility  constructor  loads 
street  names  and  shapes  into  StreetName  and 
Shape  objects.  Because  the  number  of  streets  and 
segment  shapes  actually  used  in  a  simulation  may 
vary,  but  the  street  and  shape  indexes  are  constant 
for  a  particular  county,  StreetName  and  Shape 
objects  are  placed  in  HashMap  objects,  where  the 
value  of  the  index  is  the  key  and  the  reference  to  the 
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int  streetlndex; 


object  is  the  value. 

The  RoadSegment  class  includes  the  follow¬ 
ing  fields  containing  information  provided  by  the 
USCB’s  TIGER  data  files  [15]3: 

int  startAddressLef t ; 
int  endAddressLef t ; 
int  startAddressRight ; 
int  endAddressRight ; 

Location2D  startPoint; 

Location2D  endPoint; 
char  roadClass;4 
int  numberOf LanesToStart ; 
int  numberOf LanesToFinish; 

Note  that  the  startPoint  and  endPoint  val¬ 
ues  are  assigned  arbitrarily  from  the  RoadSeg¬ 
ment  s  endpoints,  but  the  values  are  consistent  for 
the  duration  of  the  simulation  and  are  used  to  de¬ 
termine  the  trajectory  for  each  vehicle  along  the 
segment.  Also  note  that  locations  are  currently 
represented  as  two-dimensional  points  because  the 
TIGER  data  files  do  not  supply  altitude  information. 
Should  such  data  become  available,  the  system  can 
be  easily  modified  to  support  it. 

The  RoadSegment  class  also  contains  the  index 
of  the  street  name  index,  shape  index  and  index  in 
the  Vector  of  RoadSegments  as  follows: 


3  Note  that  the  Tiger  data  files  do  not  contain  information 
about  whether  a  road  segment  is  one  way.  Further,  estimates 
for  the  number  of  lanes  and  the  speed  limit  for  a  segment  are 
inferred  from  its  road  class. 

4This  assists  in  estimating  the  speed  limit  for  the  segment. 


int  shapelndex; 
int  selfindex; 

The  RoadSegment  class  maintains  several  prop¬ 
erties  that  aid  in  vehicle  management  within  and  be¬ 
tween  RoadSegments,  such  as  length  of  the  seg¬ 
ment,  the  maximum  number  of  vehicles  allowed  on 
a  segment,  the  average  vehicle  size5,  and  following- 
distance-related  constants. 

In  addition  to  these  constant  values,  the  Road¬ 
Segment  class  contains  properties  for  maintaining 
runtime  state  about  vehicles  on  each  RoadSeg¬ 
ment.  These  include  the  number  of  vehicles  on  the 
road  segment,  the  number  of  lanes  in  the  segment 
and  a  linked  list  of  vehicles  for  each  lane  in  the  seg¬ 
ment: 

int  numberOf Cars ; 

LinkedList  carsToEnd  []; 

LinkedList  carsToStart  []; 

The  remaining  classes  mentioned  in  this  section 
are  straightforward.  The  StreetName  class  main¬ 
tains  a  set  of  Strings  containing  the  street’s  prefix 
(e.g.,  N,  S,  E,  W),  name  and  suffix  (e.g.,  Ln,  Blvd, 
etc.).  The  Shape  class  represents  a  multisegment 
shape  as  an  array  of  latitude/longitude  pairs. 

5.2  Initial  Node  Placement 

Before  the  simulation  can  start,  vehicles  must  be 
placed  on  valid  locations  on  the  road  plan  for  the 
specified  region.  Currently,  the  simulator  sup¬ 
ports  a  random  placement  model,  implemented  by 

5  Our  implementation  currently  supports  only  average  vehicle 
lengths  but  can  be  extended  to  support  a  distribution  of  vehicle 
lengths,  should  the  data  become  available  to  us. 


9 


the  StreetPlacementRandom  class,  which  ex¬ 
tends  the  SWANS  simulator’s  Placement  inter¬ 
face.  This  simple  model  selects  a  RoadSegment  at 
random,  then  chooses  a  direction  and  a  lane  at  ran¬ 
dom.  To  simplify  the  implementation,  the  first  vehi¬ 
cle  in  a  lane  is  placed  at  the  front  of  the  lane  and  sub¬ 
sequent  vehicles  assigned  to  that  lane  are  placed  be¬ 
hind  the  last  vehicle  in  the  lane.  All  nodes  start  with 
zero  velocity.  Though  simple,  this  model  of  place¬ 
ment  is  sufficiently  realistic  if  vehicles  are  provided 
a  “warm-up”  period  during  which  vehicles  move,  but 
no  network  traffic  is  generated.  This  allows  the  ve¬ 
hicles  to  acquire  higher  speeds  and  to  change  streets 
before  network  performance  is  measured.  We  rou¬ 
tinely  include  a  warm-up  time  of  at  least  30  seconds 
in  each  of  our  simulation  runs. 

Future  iterations  of  the  node  placement  model  will 
include  support  for  traffic  flows  such  that  vehicles 
enter  and  exit  the  field  at  various  times  during  the 
simulation  run.  This  implementation  will  also  in¬ 
clude  support  for  incoming  flow  rates  at  various  lo¬ 
cations,  if  such  data  is  available. 

5.3  Intra-segment  mobility  implementation 

In  this  section,  we  detail  the  implementation  of  our 
intra- segment  mobility  model.  The  implementation 
consists  of  the  StreetMobility  class,  which 
implements  the  Mobility  interface  to  provide  a 
node’s  position  after  each  time  step. 

When  the  simulation  starts,  nodes  move  accord¬ 
ing  to  the  car-following  model  such  that  nodes  will 
attempt  to  accelerate  at  a  constant  rate  of  up  to  5  mph 
per  second  to  move  with  a  speed  equal  to  the  max¬ 
imum  speed  for  the  current  driver.6  This  speed  is 

6We  acknowledge  that  acceleration  rates  are  hardly  uniform 
in  real  life,  but  this  simplifying  assumption  reduces  program 
and  computational  complexity.  Future  iterations  of  the  mobil¬ 
ity  model  will  include  more  accurate  acceleration  curves  when 
such  data  becomes  available. 


equal  to  the  speed  limit  for  the  current  road  plus 
a  Gaussian  distributed  value  with  a  zero  mean  and 
a  4  mph  standard  deviation.7  The  car  will  alter  its 
speed  according  to  the  following  rules: 

•  The  car  encounters  an  intersection  and  the  next 
road  segment  on  which  it  will  travel  is  full.  In 
this  case,  the  car  stops  before  the  intersection 
and  remains  stopped  until  there  is  room  in  the 
next  road  segment. 

•  There  is  a  car  in  front  of  the  current  car.  In 
this  case,  the  node  will  slow  down  to  the  speed 
necessary  to  maintain  a  speed-based  following 
distance  between  the  current  node  and  the  node 
in  front  of  it.  We  use  the  simple  formula  cited 
in  [21]: 

S  =  a  +  pV  +  -fV2,  (1) 

where 

a  =  the  vehicle  length 

/3  =  the  reaction  time  (we  use  0.75  seconds) 

7  =  the  reciprocal  of  twice  the  maximum  av¬ 
erage  deceleration  of  the  following  vehi¬ 
cle  (we  use  the  empirically-derived  value, 
0.0070104s2  fm  [21]) 

If  the  car  in  front  of  the  current  car  is  moving 
faster  than  the  current  car,  no  speed  adjustment 
is  necessary. 

7 According  to  the  NHTSA  [1],  traffic  engineers  take  drivers’ 
perceptions  into  account  in  setting  speed  limits.  A  posted  speed 
limit  is  often  set  to  the  speed  at  which  85  percent  of  drivers  travel 
at  or  below.  However,  [6]  reports  that  observed  speeds  are  nor¬ 
mally  distributed  with  a  center  at  the  posted  speed  limit.  Un¬ 
fortunately,  we  could  not  find  a  widely  accepted  mean  for  this 
distribution. 
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•  The  car  encounters  traffic  control.  In  this  case, 
the  car  will  slow  down  (at  a  uniform  accelera¬ 
tion)  before  an  intersection  with  a  red  stoplight 
or  a  stop  sign;  if  the  stoplight  turns  green,  the 
car  attempts  to  accelerate  if  possible. 

•  The  car  turns  onto  a  new  street.  In  this  case,  the 
car  slows  down  before  the  intersection  to  make 
the  turn  at  a  reasonable  speed  (5  mph),  then  ac¬ 
celerates,  if  possible,  to  the  highest  speed  it  can 
attain  given  the  other  constraints. 

Because  nodes  for  our  experiments  (i.e.,  urban  en¬ 
vironments)  are  constrained  to  roads  in  downtown 
urban  environments  and  therefore  exhibit  average 
speeds  no  larger  that  12  m/s  for  our  experiments,  we 
update  each  node’s  position  once  per  second  using  its 
current  speed  and  direction.  We  intend  to  incorporate 
speed-based  position  updates,  among  other  features, 
in  future  iterations  of  STRAW.  It  is  also  important 
to  note  that  lane  changing  has  not  been  incorporated 
into  our  simulator  at  this  point. 

5.4  Inter-segment  mobility  implementation 

This  section  discusses  the  implementation  of  our 
inter-segment  mobility  model.  Our  simulator  sup¬ 
ports  two  levels  of  admission  control  at  an  intersec¬ 
tion. 

The  first  form  of  admission  control  simulates  com¬ 
mon  traffic  control  mechanisms.  Our  simulator  sup¬ 
ports  stop  signs  and  timed  traffic  lights.  (Lights  for 
guarded  turns  are  not  currently  supported.)  We  ex¬ 
pect  that  future  iterations  of  the  model  will  include 
triggered  lights  and  guarded  turns.  Note  that  because 
we  do  not  currently  support  lane  changing,  we  also 
do  not  consider  a  vehicle’s  current  lane  when  it  at¬ 
tempts  to  make  a  turn. 

The  Intersection  class  provides  traffic  con¬ 
trol  functionality  in  our  simulator.  In  addition  to 


maintaining  the  location  of  the  center  of  the  inter¬ 
section,  the  Intersection  object  also  contains 
other  state  information,  such  as  the  list  of  Road- 
Segments  incident  on  the  intersection,  the  number 
and  index  of  unique  streets  incident  on  the  intersec¬ 
tion  and  the  number  of  streets  of  each  road  class  for 
this  intersection.  This  class  also  contains  fields  to 
facilitate  the  synchronization  of  nodes  attempting  to 
cross  an  intersection. 

The  Intersection  class  performs  admission 
control  via  the  getPauseTime  method,  which  re¬ 
turns  the  number  of  seconds  for  which  a  node  must 
pause  at  the  intersection.  A  nonzero  value  indicates 
that  a  node  must  stop;  a  zero  value  indicates  that  the 
vehicle  may  cross  the  intersection. 

Because  real-world,  per-intersection  traffic  con¬ 
trol  information  is  unavailable,  the  simulator  cur¬ 
rently  assigns  traffic  control  to  intersections  accord¬ 
ing  to  the  class  of  road  segments  at  those  intersec¬ 
tions.  For  example,  access  to  the  intersection  be¬ 
tween  two  local/neighborhood  roads  is  controlled  by 
a  stop  sign;  access  to  the  intersection  between  “sec¬ 
ondary”  roads  and  state  highways  is  controlled  by  a 
timed  stoplight.  The  types  of  traffic  control  at  vari¬ 
ous  intersections  is  given  in  Table  1.  Our  traffic  light 
model  currently  supports  only  two  streets  (up  to  four 
road  segments)  at  an  intersection  containing  street 
lights.  Although  the  simulation  will  run  if  there  are 
more  than  two  streets  in  such  an  intersection,  it  will 
not  correctly  ensure  that  traffic  flows  without  colli¬ 
sion. 

If  the  light  is  red,  the  getPauseTime  method 
returns  the  number  of  seconds  until  the  light  turns 
green;  otherwise,  the  getPauseTime  method  re¬ 
turns  zero,  indicating  that  the  vehicle  may  cross  the 
intersection. 

For  simplicity,  we  used  timed  stoplights  that  turn 
red  and  green  at  regular  intervals  that  are  dependent 
on  the  simulation  time.  This  means  that  all  of  the 
stoplights  for  intersections  of  the  same  type  are  syn- 
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Road  Class 

Interstate 

US  Highway 

Secondary 

Urban/Rural 

Ramp 

Interstate 

stoplight  (30) 

stoplight  (30) 

stoplight)  15) 

stop  sign 

no  pause 

US  Highway 

stoplight  (30) 

stoplight  (30) 

stoplight  (15) 

stop  sign 

no  pause 

Secondary 

stoplight  (45) 

stoplight  (45) 

stoplight(30) 

stop  sign 

stop  sign 

Urban/Rural 

no  pause 

no  pause 

no  pause 

stop  sign 

stop  sign 

Ramp 

no  pause 

no  pause 

no  pause 

no  pause 

no  pause 

Table  1:  Table  of  traffic  control  and  pause  times  according  to  intersecting  street  types.  The  column  header 
represents  the  current  street  type  and  the  row  header  represents  the  intersecting  street  type.  The  values  in 
parentheses  represents  the  number  of  seconds  per  green  light  at  that  intersection. 


chronized,  an  assumption  that  is  invalid  in  the  real 
world,  in  general.  We  used  this  technique  for  its  sim¬ 
plicity. 

If  a  vehicle  encounters  a  stop  sign  at  an  intersec¬ 
tion,  the  getPauseTime  method  determines  the 
vehicle’s  stop  time  according  to  the  state  of  the  in¬ 
tersection.  In  the  simplest  case,  if  there  are  no  vehi¬ 
cles  currently  in  the  intersection  or  waiting  to  cross 
the  intersection,  the  vehicle  stops  for  one  second  and 
crosses  the  intersection.  If  the  Intersection  ob¬ 
ject  has  already  selected  a  vehicle,  Va,  to  cross  the 
intersection  and  Va  has  not  yet  crossed  the  intersec¬ 
tion,  a  different  vehicle  on  the  same  street,  but  on  the 
opposite  side  of  the  intersection  from  Va,  may  cross 
the  intersection.  Otherwise,  the  vehicle  is  added  to 
the  list  of  waiting  vehicles  and  pauses  for  three  sec¬ 
onds  (allowing  Va  to  cross  the  intersection)  before  it 
can  attempt  to  cross  the  intersection  by  calling  get¬ 
PauseTime  again. 

To  prevent  indefinite  postponement,  the  Inter¬ 
section  object  contains  a  field  that  specifies  the 
identifier  of  the  next  street  on  which  vehicles  can 
cross  the  intersection.  The  “next  street”  is  changed 
after  the  previous  street  is  serviced;  the  streets  at 
an  intersection  are  serviced  round  robin.  If  there  is 
no  contention  at  an  intersection,  however,  the  street 
with  one  ore  more  vehicles  is  serviced  immediately. 
Although  real  drivers  do  not  necessarily  behave  in 


such  a  reasonable  manner,  we  believe  that  this  model 
is  sufficiently  accurate  for  modeling  vehicle  interac¬ 
tions  at  stop- sign  intersections. 

Another  type  of  admission  control  is  regulated  by 
the  capacity  of  the  next  road  segment  on  which  the 
vehicle  will  travel.  A  node  is  not  allowed  to  move  to 
the  next  segment  unless  there  is  enough  room  on  that 
segment.  This  admission  control  is  performed  only 
after  the  traffic  control  admission  permits  the  vehicle 
to  move  to  the  next  segment. 

The  RoadSegment  class’s  addNode  method 
performs  admission  control  according  to  the  capacity 
of  lanes  in  that  segment.  In  the  current  implementa¬ 
tion,  this  method  first  finds  the  lane  with  the  fewest 
vehicles.  If  there  is  room  for  the  incoming  vehicle, 
the  method  adds  the  vehicle  to  the  lane  and  returns 
a  reference  to  the  linked  list  of  vehicles  in  that  lane, 
for  car-following  purposes.  If  there  is  not  room,  the 
method  returns  null.  If  a  vehicle  receives  null 
from  an  addNode  call  at  an  intersection  boundary, 
it  remains  at  the  intersection  threshold  until  room 
becomes  available.  In  particular,  the  vehicle  calls 
addNode  every  1/4  second  of  simulation  time  until 
the  method  returns  a  valid  reference.  At  this  point, 
the  vehicle  moves  to  the  next  segment  on  its  path, 
and  the  intra-segment  mobility  module  manages  its 
motion. 
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5.5  Per- Vehicle  State  Information 

To  manage  vehicular  mobility  efficiently,  each  ve¬ 
hicle  maintains  state  information  in  a  StreetMo- 
bilitylnfo  object.  This  state  object  allows  the 
user  to  configure  per- vehicle  settings  such  as  its  max¬ 
imum  speed,  reaction  time  and  acceleration  rate,  and 
to  maintain  information  vital  to  the  car-following  and 
inter-segment  mobility  models,  including  the  road 
segment  that  the  vehicle  is  currently  on,  the  direc¬ 
tion  it  is  moving,  the  next  road  segment  it  will  travel, 
the  vehicle  that  it  is  following,  the  current  speed  and 
the  remaining  distance  to  the  end  of  the  current  road 
segment. 

5.6  Route  Management  and  Execution 

This  section  describes  the  Route  Management  and 
Execution  (RME)  implementations  for  our  STRAW 
mobility  model.  We  consider  two  models:  state¬ 
less  intersegment  mobility  and  mobility  with  origin- 
destination  (OD)  pairs.  In  the  former  model,  the  next 
segment  to  which  a  vehicle  will  move  is  determined 
stochastically  at  each  intersection.  In  the  latter  one, 
the  decision  is  based  on  the  precomputed  shortest 
path  between  the  vehicle’s  specified  origin  and  des¬ 
tination. 

5.6.1  Simple  Intersegment  Mobility 

The  simple  intersegment  mobility  model  maintains  a 
single  value  to  determine  the  next  segment  on  which 
a  vehicle  will  travel:  the  probability  that  it  will  turn 
at  any  given  intersection.  This  probability  can  be 
shared  among  all  vehicles,  or  can  be  assigned  differ¬ 
ently  to  different  vehicles.  Although  this  model  does 
not  represent  any  real  car-driving  phenomenon,  it  is 
simple  to  implement  and  incurs  negligible  storage 
and  computation  overhead  while  producing  a  weak 


form  of  random  waypoint  mobility.8 

This  component  is  implemented  by  the  St reet- 
Mob i  1  i  t  y Ra n dom  class,  which  extends  the  Street- 
Mobility  abstract  class  by  defining  the  inherited 
setNextRoad  method.  This  method  returns  the 
next  segment  on  the  same  street  in  the  current  di¬ 
rection  of  motion  with  probability  (I -p)  and  a  road 
segment  on  a  different  street  (chosen  at  random) 
with  probability  p.  The  value  p  for  a  vehicle  is 
maintained  by  the  StreetMobilitylnf oRan- 
dom  class,  which  extends  the  StreetMobility¬ 
lnf  o  class. 

5.6.2  Mobility  with  Origin-Destination  Pairs 

This  scenario  models  vehicles  that  move  from  a  start 
point  to  an  end  point  along  a  path  that  approximately 
minimizes  trip  duration  according  to  the  speed  limit 
of  the  available  roads.  This  model  currently  supports 
three  types  of  motion:  a  single  origin  and  destina¬ 
tion  for  the  duration  of  the  experiment,  a  sequence 
of  randomly  generated  origin-destination  pairs  and  a 
sequence  of  predetermined  origin-destination  pairs. 

In  future  iterations,  we  will  extend  the  simulator  to 
support  the  abundance  of  existing  empirical  traffic 
information  that  is  expressed  in  flows  of  vehicles  per 
unit  time  at  a  road  segment. 

When  a  vehicle  is  placed  on  a  field  and  its  initial 
OD  pair  has  been  specified,  the  simulator  computes 
the  shortest  path  between  origin  and  destination.  The 
vehicle  then  follows  the  path  until  reaching  the  desti¬ 
nation.  If  another  OD  pair  is  specified,  then  the  new 
path  is  calculated;  otherwise,  the  node  is  considered 
to  have  finished  participating  in  the  simulation  and 
is  moved  off  the  map  (with  its  radio  turned  off)  to 

8We  describe  this  motion  as  “weak”  random  waypoint  be¬ 
cause  the  set  of  possible  waypoints  and  the  set  of  possible  tra¬ 
jectories  are  constrained  by  the  fixed  street  plan.  This  differs 
from  the  random  waypoint  model  in  an  open  field,  where  way- 
points  and  trajectories  are  chosen  uniformly  at  random. 
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prevent  interaction  with  other  nodes. 

This  component  uses  the  A  *  shortest  path  algo¬ 
rithm  to  find  a  near-optimal  shortest  path  while  sig¬ 
nificantly  reducing  the  range  of  the  problem  space 
explored  by  using  a  heuristic  function  that  estimates 
the  distance  to  the  goal.  For  the  purposes  of  this  com¬ 
ponent,  we  use  the  Manhattan  distance  (i.e.,  sum  of 
the  distances  along  the  two  orthogonal  axes  between 
origin  and  destination)  between  the  current  location 
and  the  destination  as  the  heuristic  for  computing  the 
estimated  remaining  distance.  To  reduce  the  num¬ 
ber  of  turns  along  a  path,  and  to  increase  the  like¬ 
lihood  of  a  fast  route,  the  algorithm  penalizes  turns 
and  non-interstate  routes  by  increasing  the  costs  of 
paths  meeting  these  criteria. 

Mobility  with  OD  pairs  is  implemented  by  the 
St reetMobilityOD  class,  which  implements 
the  StreetMobility  abstract  class  by  defin¬ 
ing  the  setNextRoad  method,  which  returns  the 
next  road  segment  along  the  vehicle’s  current  path. 
The  state  for  each  vehicle  is  represented  by  the 
St reetMobilitylnf oOD  class,  which  extends 
the  StreetMobilitylnf o  class  to  include  the 
destination  location  and  the  path  (a  linked  list  of  road 
segments)  from  origin  to  destination. 

The  A*  search  is  implemented  with  the  AS- 
tarSearch  class,  which  uses  the  SegmentN- 
ode  class  to  represent  road  segments  as  nodes  in 
a  graph.  The  SegmentNode  class  implements  the 
ASt  a r Node  abstract  class  to  provide  definitions  for 
the  heuristic  and  cost  functions.  In  the  current  im¬ 
plementation,  the  cost  of  a  particular  road  segment  is 
the  estimated  speed  limit  for  that  segment.  In  future 
iterations  of  this  component,  we  will  include  other 
sources  for  cost  analysis,  such  as  current  road  and 
traffic  conditions. 

It  is  important  to  note  that  the  A*  search  is  by  far 
the  most  computationally  intensive  part  of  our  mo¬ 
bility  model.  In  the  future,  we  will  implement  route 
caching  to  improve  performance  in  this  area. 


6  Performance 

In  this  section,  we  provide  a  brief  summary  of 
STRAW’S  performance.  For  all  of  our  figures,  we 
simulated  a  16-minute  experiment  that  included  a 
30-second  warm-up  time  and  a  30-second  resolution 
time  typical  of  network  performance  experiments. 
Each  data  point  represents  the  average  of  five  sim¬ 
ulation  runs,  and  error  bars  representing  the  standard 
deviation  are  included  if  significant.  We  used  the 
random  placement  model  described  in  Section  5.2  to 
determine  initial  node  placement.  For  STRAW  mo¬ 
bility  with  OD  pairs,  each  time  a  node  reached  a  des¬ 
tination,  we  chose  a  new  destination  at  random  and 
computed  the  shortest  path  to  that  location.  These 
simulations  were  run  on  a  server  equipped  with  an 
Intel  Xeon  2  GHz  processor.  The  simulation  ran  con¬ 
current  with  other  applications  that  consumed  ap¬ 
proximately  50%  of  the  CPU. 

Figure  2  illustrates  simulation  runtimes  accord¬ 
ing  to  numbers  of  nodes  in  the  system.  We  com¬ 
pare  the  performance  of  STRAW  in  Boston,  MA  and 
Chicago,  IL  to  that  of  the  random  waypoint  model 
in  regions  of  similar  size.  As  discussed  in  Sec¬ 
tion  5.6.1,  the  “simple”  STRAW  mobility  model  in¬ 
curs  a  small  (approximately  constant)  factor  of  run¬ 
time  overhead  compared  to  the  random  waypoint 
model.  The  STRAW  mobility  with  OD  pairs  model 
requires  a  significantly  longer  execution  time,  which 
is  due  to  the  high  cost  of  computing  shortest  paths. 
It  is  important  to  note  that  runtimes  for  this  mobility 
model  eventually  decreased  as  the  number  of  nodes 
increased.  This  occurs  because  there  is  significant 
congestion  in  the  network  (i.e.,  a  traffic  jam),  mean¬ 
ing  that  each  node  covers  less  distance  per  unit  of 
simulation  time  and  thus  will  require  fewer  shortest 
path  searches. 

Figure  3  demonstrates  how  the  simulation’s  mem¬ 
ory  consumption  varies  according  to  the  number  of 
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Runtime  vs.  Number  of  Nodes  in  Chicago  (-5,240,000  mA2)  and  Boston  (-1 ,1 60,000  mA2) 


Figure  2:  Effect  of  number  of  nodes  on  runtime 
for  STRAW  and  a  simple  random  waypoint  model 
(RWP). 

nodes  in  the  system.9  We  include  the  same  mobility 
models  as  in  the  previous  figure.  In  this  case,  the  ran¬ 
dom  waypoint  model,  which  does  not  load  any  map 
data,  provides  a  baseline  for  the  memory  consump¬ 
tion  in  STRAW.  Notice  that  the  number  of  nodes  in 
the  system  has  much  smaller  effect  on  memory  con¬ 
sumption  than  it  does  on  the  runtime.  This  indicates 
that  memory  is  not  a  significant  factor  when  scaling 
the  system  to  large  numbers  of  nodes.  In  fact,  the 
most  significant  factor  for  memory  consumption  is 
the  number  of  road  segments  in  test  region,  which 
is  directly  correlated  to  the  size  of  the  region.  For 
the  portion  of  the  Chicago  region  used  in  this  ex¬ 
periment  (approximately  2  square  miles,  370  seg¬ 
ments),  total  memory  consumption  was  between  2 
and  5  MB.  When  loading  map  data  for  the  entire  city 
of  Chicago  (230  square  miles  containing  157,120 
road  segments,  not  shown),  memory  consumption 

9Note  that  we  use  the  Java  API’s  memory  reporting  functions 
to  determine  memory  consumption.  Due  to  Java’s  garbage  col¬ 
lection  implementation,  it  is  difficult  to  determine  how  much  al¬ 
located  memory  is  actually  being  consumed.  We  attribute  anom¬ 
alies  in  the  memory  consumption  graph  to  this  property,  not  to 
any  intrinsic  properties  of  STRAW  or  the  SWANS  simulator. 


Memory  Consumption  vs.  Number  of  Nodes  in  Chicago  (-5,240,000  mA2)  and  Boston  (-1,160,000  mA2) 


Figure  3:  Effect  of  number  of  nodes  on  memory  con¬ 
sumption  for  STRAW  and  a  simple  random  waypoint 
model  (RWP). 

was  approximately  92  MB.  Although  the  size  of  the 
data  structures  supporting  STRAW  varies  during  the 
execution,  the  92  MB  value  yields  approximately  58 
bytes  of  memory  per  RoadSegment,  on  average. 

The  results  of  our  experiments  demonstrate  that, 
in  general,  one  can  successfully  model  large-scale 
realistic  vehicular  motion  on  commodity  hardware. 
Although  STRAW  with  OD  pairs  does  not  scale  as 
well  as  other  mobility  models,  its  worst-case  perfor¬ 
mance  is  bounded  by  the  finite  capacity  of  the  under¬ 
lying  road  plan. 

7  Conclusion  and  Future  Work 

This  paper  described  the  principles  and  implementa¬ 
tion  of  a  realistic  vehicular  mobility  model  for  use  in 
a  wireless  network  simulator.  We  discussed  the  mo¬ 
tivation  for  including  a  realistic  mobility  model  for 
correctly  evaluating  the  performance  of  vehicular  ad- 
hoc  networks.  Then  we  identified  implementation- 
independent  features  of  vehicular  mobility  models 
and  proposed  three  components  of  vehicular  mobil¬ 
ity  models  that  can  be  developed  and  enhanced  in- 
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dependently  to  improve  realism.  Next,  we  detailed 
our  implementation  of  the  STRAW  (STreet  RAndom 
Waypoint)  vehicular  mobility  model  and  its  support¬ 
ing  components,  such  as  the  street  placement  model, 
the  car-following  intra- segment  mobility  implemen¬ 
tation,  basic  traffic  control  implementations  and  the 
route  management  and  execution  implementations. 
Finally,  we  demonstrated  that  STRAW  mobility  pro¬ 
vides  reasonable  runtimes  and  memory  consumption 
that  scales  fairly  well  with  the  size  of  the  simulation. 

Although  we  believe  that  our  model  is  a  signifi¬ 
cant  improvement  over  the  random  waypoint  model 
and  other  similar  vehicular  mobility  models,  we  ac¬ 
knowledge  that  there  are  several  important  details 
that  may  further  enhance  the  realism  of  the  mobil¬ 
ity  model.  For  example,  most  empirical  traffic  data 
concerns  traffic  flows;  i.e.,  counts  of  vehicles  enter¬ 
ing  (and/or  exiting)  a  road  segment  per  unit  time.  We 
intend  to  extend  our  mobility  model  to  support  such 
traffic  flows.  Another  important  aspect  of  vehicular 
motion  is  lane  changing.  In  the  future,  we  will  im¬ 
plement  lane  changing  and  ensure  that  vehicles  must 
be  located  in  the  correct  lane  before  turning  at  an 
intersection,  for  example.  We  are  also  interested  in 
implementing  the  capability  to  calculate  the  shortest 
path  between  origin  and  destination  by  including  the 
current  average  vehicle  speed  on  a  segment  to  de¬ 
termine  the  cost  of  a  segment.  Finally,  performance 
analysis  and  optimization  of  our  system  is  part  of  our 
future  work. 
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C3  -  Car-to-Car  Cooperation 


•  An  opportunity 

-  Computers  everywhere  -  -100  in  a  BMW  7x 

-  Increased  interconnectivity  (adv.  in  wireless  communication) 

-  A  large  &  well  spread  platform  -  growing  vehicle  population 

-  Good  &  accessible  location  information 


Distributed  systems  based  on  car-to-car  cooperation 

•  Some  example  applications 

-  Traffic  advisory 

-  Mobile  sensor  network  for  recognizance _ 

•  A  few  key  properties 

-  Self-organizable  &  infrastructure  independent 

-  Natural  scalability 

-  Highly  resilient  to  failure 
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A  challenge  for  experimenters 

•  C3  -  a  mobile  ad-hoc  network  over  vehicles 

-  Infrastructureless  networks  (ad-hoc  networks) 

-  Nodes  act  as  routers  finding/maintaining  routes  to  others 

-  Nodes  are  capable  of  movement  &  can  be  connected 
dynamically  in  an  arbitrary  manner  (MANETS) 

*  The  challenge  -  How  can  we  play  with  our  ideas  for 
such  systems? 

-  Real-world  experimentation 

•  Currently  no  test-bed  available 

•  Hard  to  explore  scalability 

•  Classical  problem  with  repeatability 
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An  experimenters'  challenge 


•  Emulation 

-  Uses  real  sw/hw  in  simulated  environment  to  ensure  accuracy 

-  Higher  scalability,  but  still  limited 

Network  simulation  (e.g.  NS-2,  GloMoSim,  SWANS) 

-  Scalable  to  large  number  of  nodes 

-  Easy  to  vary  system  configuration 

-  Repeatability 

•  Desirable  simulation  characteristics 

-  Close  correspondence  with  real  world  -  trace-based  simulation?  ... 

-  Generalizable  -  should  enable  a  wide  range  of  scenarios 

-  Feedback  loop  -  enable  self-steering  (e.g.,  traffic  advisory) 

-  Scalability  -  interesting  problem  instances 
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Outline 


•  C3  motivation  &  approach 

•  Mobility  models  for  MANETs 

•  STRAW  design  and  implementation 

•  STRAW  performance 

•  Conclusion  and  future  directions 
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The  importance  of  a  mobility  model 

•  Mobility  -  key  component  of  MANET  simulators 
&  emulators 

-  Mobility  constraints  (e.g.,  streets) 

•  Affects  velocities  and  distances  between  cars,  which 
affects  radio  transmission 

-  Nodes  should  physically  interact  with  one  another 

•  E.g.,  avoid  collisions 

-  Central  to  “feedback  loop”  in  many  scenarios 

•  Cars  can  change  trajectory  in  response  to  data 

-  What’s  commonly  used? 

•  Random  waypoint,  Mobility  traces, ... 


AquaLab 
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Random  Waypoint  considered  harmful 


•  Random  Waypoint  (RWP) 

-  Benefits 

•  Simple 

•  Common 

•  Low  overhead 

-  Disadvantages 

•  NOT  representative  of 
mobility  for  worst-case  or 
general-case  performance 

•  Nodes  cannot  interact  wrt 
mobility 

•  Encourages  use  of  open 
field  simulation 


• 

• 

• 

• 

• 

• 

• 

• 

Dept,  of  Computer  Science 
Northwestern  University 


RWP  effects  on  wireless  communication 

•  Every  position  on  map  is  a  waypoint  with 
equal  probability 

-  Average  number  of  neighbors  is  relatively  uniform 
over  the  field 

•  Nodes  generally  cannot  leave  the  field 

-  Routes  generally  live  longer 

•  Arbitrary  stopping  points  and  stopping  times 

-  Affects  route  lifetimes  arbitrarily 

•  Arbitrary  speeds  and  speed  distributions 
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Mobi  I  ity  traces 


•  Advantages 

-  Represents  real  motion 

-  Little  overhead  in  simulation 

•  Disadvantages 

-  Difficult  to  obtain 

-  Rarely  distributed  (legal  issues) 

-  Difficult  to  generalize 

-  Does  not  allow  feedback  loop 
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Vehicular  motion 


Stoplight 


Car  mobility  &  wireless  communication 


AquaLab 


•  Nodes  tend  to  spend  more  time  at  intersections 

-  Increases  interference  in  this  region 

-  Increases  number  of  unconnected  pairs 

•  Buildings  further  reduce  connectivity  between  nodes 
on  different  streets 

•  Nodes  often  traveling  in  opposite  or  orthogonal 
directions 

-  Short  interaction  time  window 

•  Vehicular  congestion  slows  nodes 

-  Can  stabilize  topology,  but  can  reduce  overall  connectivity 

•  We  need  a  new  mobility  model:  STRAW 
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Outline 


•  C3  motivation  &  approach 

•  Mobility  models  for  MANETs 

•  STRAW  design  and  implementation 

•  STRAW  performance 

•  Conclusion  and  future  directions 
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STRAW  (Street  Random  Waypoint) 


•  Node  movement  incorporates 

-  Car-following  model 

-  Speed  limits 

-  T raffic  control 

-  Multiple  lanes 

•  Loads  free  map  data  for  entire  US  (easily  extended 
to  load  data  from  other  map  sources) 

•  Low  overhead 

-  Insignificant  for  “simple”  model 

-  Bounded  by  vehicular  capacity  of  region  for  shortest-path 
origin-destination  (OD)  calculations 

•  Easy  to  configure 
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Basic  abstractions  for  vehicular  motion 

•  Vehicle  (containing  finite  length) 

•  Road  Segment 

-  Shape 

-  Length 

-  Width 

-  Name 

-  Average  maximum  speed  (speed  limit) 

-  Class 

-  Address 

•  Intersection 
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Packet  delivery  ratio 


II 


Some  implications  of  STRAW 


Packet  Delivery  Ratio  for  DSR  in  Boston,  Chicago  and  an  Open  Field  (100  nodes) 
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STRAW  organization 


AquaLab 


STRAW  mobility  model 


/ 


Route  mgmt  &  execution  component 


Constrained 
random  mobility 


Trip  plans  - 
origin-destination 
pairs 


Inter-segment  mobility  component 


Stoplights 


Access 

ramps 


Intra-segment  mobility  component 
(Car-following  model  only) 
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Per-vehicle  state 


STRAW  initialization 


m  hi  mm  mm i 


•  Loads  road  segments,  names  &  shapes  for 

rectangular  region 

-  Organized  into  a  quad  tree,  with  intersections  at 
the  leaves 

•  Intersections  contain  a  list  of  associated  road  segments 

•  Manage  inter-segment  mobility 

-  Number  of  lanes,  speed  limit,  traffic  control 
inferred  from  “road  class” 

•  Nodes  placed  on  random  streets  &  lanes 

-  If  a  node  is  already  in  that  lane,  put  new  one 
behind  last  node  in  the  lane 

-  All  nodes  start  with  zero  velocity 
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I  ntra- segment  mobility 


•  Car-following  model 

-  Speed-based  following  distance 

•  Cruising  speed 

-  Each  vehicle  moves  at  a  speed  distributed  about 
the  speed  limit  for  the  current  segment 

•  Acceleration/Deceleration 

-  Currently  linear,  can  be  extended  to  any  curve 
made  available 
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I  nter- segment  mobility 

mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmi 

•  Precondition  for  all  segment  changes  -  there 
is  capacity  on  the  next  segment 

•  Timed  stoplights 

-  Wait  times  inferred  from  road  classes 

•  Stop  signs 

-  Drivers  take  turns  crossing  the  intersection 

•  Highway  merge 

-  No  need  to  stop  if  there  is  room 

•  Nodes  gradually  slow  down  to  a  stop  before 
the  intersection  if  they  cannot  cross  it 
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Route  management  &  execution 

•  Simple  STRAW 

-  Turn  with  certain  probability 

-  Insignificant  overhead 

•  STRAW  with  OD 

-  Pick  a  series  of  origins  and  destinations 

-  Overhead  scales  with  size  of  region 

-  Uses  efficient  A*  shortest  path  search 

-  Supports  flows  of  vehicles  from  an  origin  to  a 
destination 

•  Vehicles  removed  from  communication  participation 
when  they  leave  the  map 
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Outline 


•  C3  motivation  &  approach 

•  Mobility  models  for  MANETs 

•  STRAW  design  and  implementation 

•  STRAW  performance 

•  Conclusion  and  future  directions 
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STRAW  current  implementation 

•  Implemented  as  part  of  SWANS  (Scalable 
Wireless  Ad-hoc  Network  Simulator) 

•  SWANS  features 

-  Built  atop  Java  in  Simulation  Time  (JiST) 

-  Automates  porting  to  Java  application  code  to  the 
simulator 

-  Very  efficient  and  scalable  discrete  event  sim 

-  Natural  programming  model 

-  Very  modular  and  extensible,  supports  all 
important  MANET  abstractions 
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A  sample  of  SWANS  performance 


Log-log  scale 


100 


Simulation  event  throughput 


- reference 

JiST  (cold) 
JiST  (warm) 
— b-  Parsec 

GloMoSim 
ns2  (C) 

-■'v-  ns2  (Tel) 


1  10 
#  of  events  (in  millions) 


100 


From:  BARR,  R.  An  efficient,  unifying  approach  to  simuiation 
using  virtual  machines.  PhD  thesis,  Cornell  University,  2004. 
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Runtime  (s) 


How  much  does  STRAW  cost? 


•  Reasonable  runtime  overhead 


Runtime  vs.  Number  of  Nodes  in  Chicago  and  Boston  (-5.000,000  mA2)  Runtime  vs.  Size  of  Region  in  Chicago  and  Boston  (100  nodes) 


Runtime  overhead  (log-log  scale) 
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Memory  consumption  (MB) 


How  much  does  STRAW  cost? 


•  Reasonably  small  memory  overhead 

Memory  Consumption  vs.  Number  of  Nodes  in  Chicago  and  Boston  (-5,000,000  mA2)  Memory  Consumption  vs.  Size  of  Region  in  Chicago  and  Boston  (100  nodes) 


•  Greater  Chicago’s  Cook  County  »  92MB 
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Conclusion  &  Future  directions 
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•  Summary 

-  Mobility  significantly  impacts  network  perf. 

-  Performance  varies  with  road  plan 

-  STRAW  models  VANET  mobility  with  low 
overhead 

•  Future  directions 

-  STRAW  implications  on  the  effectiveness  of 
location-based,  mobility-aware  communication 
protocols 

-  Middleware  for  VANET  applications 

-  Content  distribution  on  VANETs 
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